%This template was prepared by Dr G J Gibbon
%School of Electrical and Information Engineering
%University of the Witwatersrand
%25/3/2001
%This simple format to be used for reports submitted to the School
%The table of contents may not be necessary for short reports
%
%
%rename (the name you want) this document with extension .tex

\documentclass[10pt,twocolumn]{witseiepaper}
\usepackage{KJN}
\usepackage{stfloats}
\usepackage{fixltx2e}
\usepackage{ctable}
\usepackage{url}
\usepackage{fix2col}
\usepackage{multicol}
\usepackage{color}
%
% PDF Info
%
\ifpdf
\pdfinfo{
/Title (Wits Morabaraba)
/Author (Benjamin M. Sim, Bradley R. C. Marques, Emily Smith)
/CreationDate (D:201104090936)
/ModDate (D:201103300655)
/Subject (ELEN4009, 2011)
/Keywords (ELEN4009,  Game design, Game development, Software Design, Software engineering)
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}

\title{Wits Morabaraba \\ Group Report \\ Version 0.2}

\author{ Bradley R. C. Marques, Benjamin M. Sim, Emily Smith}
\thanks{School of Electrical \& Information Engineering, University of the
Witwatersrand, Private Bag 3, 2050, Johannesburg, South Africa}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
\abstract{A digital rendition of the African board game Morabaraba was designed by a team of four individuals.  The design process completed represents a foundation upon which a hypothetical game design studio could base an economically competitive product.  The design culminated in the production of a documentation set by each of member of the design team.  The scrum iterative development methodology is to be employed by the game studio.  A project management tool, \textit{aceProject} was used for the design process.  CMMI analysis of the design documentation reveals that the areas of project management, requirement engineering risk analysis and architecture design are mature in their implementation.  The areas of class design, user interface design, testing suite design and maintainability analysis are deemed foundational and immature.}

\keywords{ELEN4009,  Game design, Game development, Software Design, Software engineering}

\maketitle
\thispagestyle{empty}\pagestyle{empty}

\section{Introduction}
\subsection{Report Overview}

This document serves as a capstone to a documentation suite detailing the game design aspects of a digital rendition of the Morabaraba board game.  This collection of documents was formed to meet the proposed problem statement [Section \ref{sec:problem_statement}] by a team of four designers.  Aspects of the project life cycle employed in this design and proposed for the hypothetical development of the game are highlighted [Section \ref{sec:project_life_cycle}].  Specifically, the chosen agile development methodology of scrum is explored [Section \ref{sec:scrum}] and the design team structure is presented and justified [Section \ref{sec:team}].  The CMMI method is employed to critically analyse the actual design product - the documentation set generated - and the process of design is qualitatively analyses [Sections \ref{sec:analysis_of_design_product} and \ref{sec:analysis_of_design_process}]. This is followed by a brief conclusion and recapitulation of the document [Section \ref{sec:conclusion}].

\subsection{Problem Statement}
\label{sec:problem_statement}

A design documentation suite for the potential creation of a software implementation of Morabaraba was developed.  This design documentation package represents the initial design phase groundwork that could hypothetically be used by a game design studio to create an economically viable and competitive benchmark of the game.  [1] specifies in detail the chosen software life cycle model and project management methodologies - the scrum agile development technique - to be employed by the game studio.  Both requirement development and requirement management strategies, such as user stores, use case models, non-functional requirements, requirement change requests and requirement traceability diagrams are developed in [1].  A three-tier software design architecture is used to establish the high-level design of the game system as in [2], and lower-level class design is presented in [3].  Non-structural but still critical aspects of game design - such as user-application interaction, graphical and audio theme - are also investigated in [1].  Project life cycle components of maintenance and testability are developed in [4].

\section{Project Life Cycle}
\label{sec:project_life_cycle}
\subsection{Adjusted Scrum Software Development Methodology}
\label{sec:scrum}
Scrum is a form of agile development, which is based around the concept of multiple shorter development stages, sprints, at the end of each a release-ready product can be released to the client. The team setups a list known as a product backlog which contains a hierarchical list of product feature or requirements that need to be completed. During each sprint the team selects a few of the most important items from the product backlog and short lists them for the next sprint. This shortened list is known as the sprint backlog. These iterations continue until such time as the product backlog is completed.\\
\\
One of the key issues with agile development is code quality and standardisation. Due to the smaller developmental stages, where both design, implementation and testing are completed often compatibility, or solution quality, for later components is compromised. Hence, to improve this a detailed system design prior to the scrums is necessary, such as this document aims to fulfil. This adjusted scrum methodology provides enhanced solution quality whilst still retaining the advantages of an agile team, such as design flexibility.

\subsection{Design Team Structure}
\label{sec:team}

The game design team consisted of four students as depicted in Table \ref{tab:team_structure}.  

\begin{table}[htb]
    \caption{Members of the Design Team\label{tab:team_structure}}
    \begin{center}
        \begin{tabular}{p{10mm}p{10mm}p{40mm}p{10mm}}
        \hline
			Name & Degree & Roles \\ \hline
			Bradley Marques & Information Engineering & \begin{itemize}
	\item Requirements Engineer
	\item Game Design
\end{itemize}\\ \hline
			Bhaviata Pharboo & Computer Science & \begin{itemize}
	\item Lead Programmer - Class design
\end{itemize}\\ \hline
			Benjamin Sim & Information Engineering & \begin{itemize}
	\item Project Manager
	\item Software Architect
\end{itemize}\\ \hline
			Emily Smith & Computer Science & \begin{itemize}
	\item Risk Analyst
	\item Testing and QA 
\end{itemize}\\ \hline
	\end{tabular}
	\end{center}
\end{table}


\subsection{Game Design Process}
\label{sec:game_design_process}

The design process was initially coordinated through a number of short, face-to-face meetings amongst group members.  The first of these saw the compartmentalisation of the game design process into the sub-process of project management, requirements engineering, project risk analysis, architecture design, class design, user interface design, testing suite design and software maintainability.  These sub-processes were assigned to the design team members as depicted in Table \ref{tab:team_structure}, according to the perceived strengths of the respective task overseers.

The proposed design process was to take the form of scrum, with iterative development of all aspects of the project followed by meetings to critique the work produced followed by subsequent necessary changes.  However, this was not the form ultimately obtained, as discussed in detail in Section \ref{sec:analysis_of_design_process}.  Rather, the design phase resembled the waterfall model, with a more sequential development process.

To encourage early communication amongst group members, a project wiki was established on Google sites\footnote{https://sites.google.com/site/witsmorabaraba/}.  It was intended that this be used as a centralised means of communicating messages and hosting collaborative documents.  This was later abandoned for the use of a dedicated project hosting site, \textit{aceProject} [5].  Section \ref{sec:analysis_of_design_process} provides a critical analysis of this decision, as well as the game design process as a whole.

\subsection{Game Testing Process}
\label{sec:game_testing}
The overall testing methodology used throughout the project was a functional or black box testing technique. In this way the implementation of the requirements and design phases were tested against the specifications laid out by the IEEE standards in order to determine the validity of the overall design and requirements. The key attributes contributing towards a successful document are: completeness, consistency, feasibility and testability. These attributes were tested by means of manual techniques such as reading, inspections and walkthrough. In addition, coverage-based testing was used to trace elements from the design documentation back to the requirements documentation in order to determine the overall completeness and feasibility of the design.

\subsection{Risk Analysis}
\label{sec:risk_analysis}
To prevent certain factors from being detrimental to the progress of the project formal risk analysis documentation needed to be developed. This was done so that the group members would be able to take precaution during the software development so as to prevent any of the risks outlined from coming into fruition.

\subsection{Funding}
The function point analysis of the project as conducted in [2], reveals that the project is not of grand scope, and well within the capability of completion by a small design team in the span of ten weeks.  As mentioned in [1], the chosen game development environment of \textit{Unity3D} is free for download.  Hence, the main factor negatively influencing the hypothetical game design studio's profit is the labour costs of the design team.

To generate income, it is proposed that the game development studio not charge for the game application download.  Instead, individual game matches should be charged for.  For instance, a player should be able to purchase the right to play a certain number of matches, and have to pay extra to play more.  Furthermore, it is proposed that the initial download of the game come bundled with a certain number of free matches. By this piecemeal income model, a player is able to download and play the game for free for a while.  The games awarded for free are intended to get the player addicted to the psychological reward feedback cycle described in [1], and the number of free games should be chosen based on extensive beta testing and market research.

\section{Game Design}

The game design is to address a rather obscure game and introduce it into the world of Western-dominating gaming.  This is discussed in detail in [1]. Users in the realm of modern sociotechnological trends of the social networking layer - such as \textit{Facebook}, \textit{Twitter} and so forth - have needs dictated by this environment.  Specifically, the needs and expectations of social interactivity and online competition are paramount in the design of the game.  The proposed game design caters for these needs by a ranked multiplayer tournament mode, a friendly multiplayer mode, leaderboards and obtainable achievements.  Players are able to view these game components as well as various statistics of their gameplay that are collected.  Users are able to use their Google accounts to register the game.  For a full account of the requirements engineering process, the reader is referred to [1].

The game is to be developed using the Unity3D game engine, for reasons explained [1], and is to be supported on web-browser, \textit{iOS} and \textit{Android} handsets.

\section{Critical Analysis}
\label{sec:critical_analysis}
\subsection{Analysis of Design Product}
\label{sec:analysis_of_design_product}

The Carnegie Melon CMMI\footnote{Capability Maturity Model Integration} model is used for the purposes of analysing the product of the design process - the documentation set produced.  Each element of the project, as defined in Section \ref{sec:game_design_process} is subjected to this model, as depicted in Figure \ref{fig:CMMI}.  Numerical scores from 0 - 5 are assigned to the developed project areas and relate to states of incomplete, performed, managed, defined, quantitatively managed and optimising, respectively.

\begin{figure}[t]
\centering
\includegraphics[width = 8cm]{CMMI.png}
\caption{CMMI analysis of design product set}
\label{fig:CMMI}
\end{figure}

The project management sphere developed in [1], includes the quantitative analysis of team size, project development life cycle and identification of scrum dates.  Thus, although always subject to inevitable change, it is determined to be a well-developed, contextualised and mature project management strategy.  The usage of scrum and continual sprint meetings adds the feedback cycle to deal with project change, and thus the area od project management involves the continual measurement and adaptability to change.

Due to the identification and prioritisation of both functional and non-functional requirements, and the development of requirements change management strategies as in [1], the requirements engineering process is deemed to be a proactive one that is used in conjunction with the chosen scrum development.  The requirements engineering aspect of the project is thus deemed contextualised and proactive.

The risk analysis presented in [4] takes into account the probability of risk areas and the impact that these have on the project time budget.  Due to this attention to detail in anticipating areas of risk and quantifying them, the risk analysis element of the project is deemed adequate in proactivity.

The in-depth design of the system-wide architecture and communication protocols in [2] anticipate needed communication channels between client and server.  Whilst, as always, the project component is subject to change (upon hypothetical implementation), this anticipatory action lends itself to a mature model of system architecture.

The lower-level class diagrams of [3], whilst acting as a possible starting point for further design, are generally not detailed enough or are incomplete.  Thus, this aspect of project design is considered as only foundational for theoretical game developers.

The user interface design of [1] whilst containing some degree of prototyping, may be considered inadequate to the game design as a whole.  While presenting the skeleton of menu logic flow and a few metadata components, not all situations are considered.  Thus, this area of project development also represents a foundational stage.

The testing suite presented in [4] and maintainability analysis of [3] bear no quantifiable basis.  They are thus determined fairly ill-formed and immature areas of the project design.

\subsection{Analysis of Design Process}
\label{sec:analysis_of_design_process}

As mentioned in Section \ref{sec:game_design_process}, an online project management toolkit, \textit{aceProject}, was used for communication, project management and document hosting.  This resulted in the majority of communication between group members being of electronic format.  This served the team positively in that documentation was made easily available for review and critique as opposed to personal meetings with hard copies of the information.  \textit{AceProject} also performed as a good repository for all the group members' contributions to the project and allowed each individual to precisely log their time and efforts on their areas of work.  However, the The lack of frequent face-to-face meetings resulted in various miscommunications between group members.  These miscommunications are seen as the cause of inconsistencies in the documentation suite [Section \ref{sec:analysis_of_design_product}].  For instance, when group members had queries relating to their individual aspects of the project, responses could not be received immediately as with a personal meeting; instead the individual would have to wait for an electronic response which also has the possibility of causing delays.

On April 7th the project was subject to a reassigning of roles that were felt to be better fitted to each individual and, as a result, delays were caused in the overall progress of the project development. However, loss of time was minimised by members drawing from existing work on the project and adding their own contributions to it so as to allow significant time for the remainder of the project to be completed.

\section{Conclusion}
\label{sec:conclusion}

The design phase of a hypothetical digital version of the Morabaraba board game was developed by a team of four students.  The result of this process was a documentation suite detailing the areas of project management, requirements engineering, project risk analysis, architecture design, class design, user interface design, testing suite design and software maintainability.  The tasks were adopted by the group members and documented in their respective individual reports.  A CMMI analysis of performed work has been presented.  Problem areas identified were low-level class design, user interface design, testing suite design and software maintainability analysis.

\section{References}
\label{sec:references}
\begin{enumerate}
    \item B. Marques, \textit{Wits Morabaraba: Requirements Engineering and User Interface Design}, School of Electrical and Information Engineering, University of the Witwatersrand, Johannesburg, South Africa, 3 May 2011
\item B. Sim, \textit{Wits Morabaraba Project Management and Software Architecture}, School of Electrical and Information Engineering, University of the Witwatersrand, Johannesburg, South Africa, 3 May 2011
\item B. Parbhoo, \textit{Wits Morabaraba: Design Documentation}, School of Electrical and Information Engineering, University of the Witwatersrand, Johannesburg, South Africa, 3 May 2011
\item E. Smith, \textit{Wits Morabaraba: Testing and Risk Analysis Documentation}, School of Electrical and Information Engineering, University of the Witwatersrand, Johannesburg, South Africa, 3 May 2011
\item \textit{aceProject}, Free Web-Based Project Management Software and Timesheet Tracking System, http://www.aceproject.com//, last accessed 2 May 2011
\end{enumerate}

\pagebreak

\end{document}

